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Applicants submit that the pending claims are allowable for the reasons set forth in their 
Response filed December 19, 2008. For the convenience of the reviewers, remarks from the 
December 19 Response are reproduced below. Several additional comments follow. 

From Applicants' December 19, 2009. Response 

The Office action rejected claims 1-16 under 35 U.S.C. § 103 based on U.S. Patent 
7,143,435 (Droms et al., hereinafter "Droms'O, U.S. Patent 5,884,024 (Lim et al., hereinafter 
"Lim") and U.S. Patent Application Pub. No. 2003/0005047 (Seki et al., hereinafter "Seki"). 
Applicants respectfully traverse. Even if a person of ordinary skill would have had reason to 
combine teachings of Droms, Lim and Seki, which Applicants do not concede, the combination 
would not teach all features of the independent claims. 

Claim 1 is directed to a method in which a DHCP relay is used to modify the protocol 
field in the DHCP messages so as to control the interaction between the DHCP server and the 
DHCP client. The Office action admits at page 3 that Droms and Lim fail to teach the following 
features of claim 1: 

wherein modifying the one or more protocol fields includes: 

upon receiving a DHCP message for request sent from the DHCP client to 
the DHCP server, filling in at least one field associated with the DHCP relay in 
the DHCP message for request, and 

upon receiving a DHCP message for response sent from the DHCP server 
to the DHCP client, replacing at least one server parameter of a field associated 
with the DHCP server in the DHCP message for response with at least one relay 
parameter of the DHCP relay. 

The Office action then asserts that these features are taught by Seki. However, the 
teachings of Seki do not relate to DHCP messages. Instead, Seki describes a data transfer 
method using a caching technique and/or a compression technique to reduce network load 
between data transfer devices. A server side proxy 30 replaces the reply data of a reply message 
received from a server 20 with a corresponding "fingerprint" registered in a fingerprint cache 34, 
and transfers the resulting reply message to the client side proxy 40. The purpose of the 
technique described in Seki is to reduce network load by transferring a fingerprint instead of 
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actual data; the fingerprint is replaced with the actual data at the client side proxy. No part of 
Seki suggests that the data replaced with a fingerprint is data within a DHCP message. Even if 
some part of a message in Droms or Lim was replaced with a fingerprint, there is nothing to 
suggest (and the Office has not explained why) the replaced portion would be a server parameter 
field associated with a DHCP server. Accordingly, Seki fails to teach "upon receiving a DHCP 
message for request sent from the DHCP client to the DHCP server, filling in at least one field 
associated with the DHCP relay in the DHCP message for request" and similarly fails to teach 
"upon receiving a DHCP message for response sent from the DHCP server to the DHCP client, 
replacing at least one server parameter of a field associated with the DHCP server in the DHCP 
message for response with at least one relay parameter of the DHCP relay." 

Moreover, a person of ordinary skill would not have had reason to combine teachings of 
Droms and Lim with teachings from Seki. As justification for the combination, the Office action 
asserts that "it would have been obvious ... to modify or incorporate Seki's teachings of replacing 
data in messages from a server with Droms-Lim's [sic] to provide for a more efficient messaging 
system." The Office has not explained how such a combination would increase efficiency. For 
example, the Office has not explained how utilization of Seki's method of replacing data with a 
"fingerprint" at one server and then replacing the fingerprint with the actual data at another 
server will make communications more efficient. If anything, it would seem that combination of 
Seki with Droms would decrease efficiency. For example, Droms describes a DHCP relay 
sending a RADIUS authentication result of an original physical port access request of a DHCP 
client's host to a DHCP server for the authentication and address assignment process by means 
of DHCP information. The function of the DHCP relay is to carry the RADIUS authentication 
result message by forwarding the DHCP Message between the DHCP client and the DHCP 
server. It is not clear how replacing some portion of the forwarded DHCP Message with a 
"fingerprint" of the replaced portion would improve efficiency. 

For at least the above reasons, claim 1 is allowable. Claims 2-8 depend from claim 1 and 
are thus allowable for the same reasons as claim 1, and because of additional recited features. 
For example, claims 4 recites "wherein for a DHCPDISCOVER or DHCPREQUEST message 
sent from the DHCP client to the DHCP server, the DHCP relay fills in the at least one field 
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associated with the DHCP relay with a value so that a DHCPOFFER, DHCPACK or DHCPNAK 
response from the DHCP server to the DHCP client can be sent to the DHCP relay." The Office 
action asserts at page 6 that Lim teaches this feature at Figures 5 and 6 and in the Abstract. In 
Lim, the DHCP relay embeds a trusted identifier in the DHCPREQUEST message and the 
DHCP server controls the number of the IP addresses which could be allocated according to the 
trusted identifier. This is different from claim 4, which recites filling in a field value so as to 
cause certain specified messages to be sent to the DHCP relay. Lim does not indicate that the 
inclusion of a trusted identifier causes one of the message types recited by claim 4 to be sent to 
the DHCP relay. For example, it is not clear from Lim that omitting the trusted identifier would 
cause one of the specified messages to go somewhere other than a DHCP relay. 

Independent claim 9 recites a DHCP relay configured to perform operations similar to 
steps recited in claim 1, and is thus allowable for the same reasons as claim 1. Claims 10-13 
depend from claim 9 and are thus allowable for at least the same reasons as claim 9. 

Independent claim 14 recites features similar to those discussed above in connection with 
claim 1, and is thus allowable for the same reasons as claim 1. Claims 15 and 16 depend from 
claim 9 and are thus allowable for at least the same reasons as claim 9. 

Additional Comments 

Page 3 of the September 19, 2008, final Office action contains the following admission: 

However, Droms-Ltm does not explicitly disclose wherein modifying the 
one or more protocol fields includes: 

upon receiving a DHCP message for request sent from the DHCP client to the 
DHCP server, filling In at least one field associated with the DHCP relay in the 
DHCP message for request, and 

upon receiving a DHCP message for response sent from the DHCP server 
to the DHCP client, replacing at least one server parameter of a field associated 
with the DHCP server In the DHCP message for response with at least one relay 
parameter of the DHCP relay. 
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The Advisory Action mailed January 22, 2009, includes the following comment: 

In response to 2). the examiner respectfully disagrees. Droms-Lim-Sekt discloses: 
upon receiving a DHCP message for request sent from the DHCP client to 

the DHCP server (Lim: Figure 7 [702]; receiving a DHCP request), filling in at least one field associated with the DHCP relay in the DHCP 
nnessage for request (Lim: Figures 2-9, and Abstract and Cd. 5 lines 10-48; DHCPACK includes tease duration and other configuration 
information that dient requested further more the embedding of the trusted identifier is filling in at least one Held associated with the DHCP 
relay in the DHCP message for request. Encoding the options field vi/ith vendor specific information), and 
upon receiving a DHCP message for response sent from the DHCP server 

to the DHCP client, replacing at least one server parameter of a field associated with the DHCP server in the DHCP message for response 
with at least one relay parameter of the DHCP relay (Lim: Figures 2-9; the sending of a DHCPACK with lease information and the 
embedding of the trusted identifiers from the relay agent). 

Notably, the above comment from the advisory action contains no cite to Seki in support 
of its assertion about what "Droms-Lim-Seki" purportedly discloses. Moreover, the assertion 
that "Lim: Figures 2-9; the sending of a DHCPACK with lease information and the embedding 
of the trusted identifiers from the relay agent" teaches the claim feature of "upon receiving a 
DHCP message for response sent from the DHCP server to the DHCP client, replacing at least 
one server parameter of a field associated with the DHCP server in the DHCP message for 
response with at least one relay parameter of the DHCP relay" is not correct. The cited portion 
of Lim seems to relate to extracting information from messages going from a client to a server, 
not replacing a parameter of a message going to a client from a server. 

Applicants respectfully submit that the remaining comments in the Advisory Action 
similarly fail to rebut the arguments from Applicants' December 19 Response. 
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